1. Field of the Invention
The present invention relates to a method and program for communication of data between an application program, which calls an API (Application Programming Interface) supplied by an operating system, and a printer driver called by the operating system.
2. Description of the Related Art
An application program for printing acquires various printing-related information via an API generally provided by an operating system (“OS” below) and notifies of print settings.
The application program calls the function of the OS-provided API in order to acquire the capabilities of the printer. The OS queries a printer driver regarding the capabilities of the printer and returns the acquired capabilities information to the application program. The application program utilizes the returned printer capabilities information to decide the print settings used when printing is performed. The application program then calls the OS-provided API to thereby notify the OS and printer driver of the print settings.
By way of example, the type of paper that can be handled depends upon printer capabilities. Accordingly, the application program acquires a list of paper types that can be handled by the printer performing the printing. The types of paper usable in printing are designated by the user or application program. In a case where the user is allowed to make the designation, the application program displays the acquired list of paper types on a display screen and the user is allowed to select the type of paper used in printing. A collection of selected values of setting items selected by the user in order to be used at the time of printing is referred to as the print settings. The OS or printer driver can be notified of these print settings in response to the application program calling the API provided by the OS. In addition to type of paper, other examples of ordinary setting items that can be mentioned are paper size and method of feed, double-sided printing, printing orientation and number of copies, etc.
In the case of the Windows (registered trademark) operating system from Microsoft, information relating to ordinary setting items such as the type of paper that can be handled by a printer can be acquired via an API referred to as a “DeviceCapabilities function”. By calling the function for every information category of setting item as in a list of paper type IDs, the application program can acquire a list of setting values on a per-category basis. Further, the information concerning the print settings used in printing can be reported from the application program to the OS or printer driver by calling an API referred to as a “Create DC function” or “Reset DC function”.
On the other hand, information relating to printer-specific features often cannot be acquired with a default API function provided by the OS. For example, with borderless printing used frequently in the printing of photographs, the amount of protrusion or “extension” beyond the size of the paper generally can be designated because it is required that the image be printed in an area larger than the paper size. The reason for this is an assumption that the user may set the paper in the printer in a skewed manner or that the paper will become skewed during its transport through the printer even if the paper has been set correctly. Accordingly, the set value of amount of extension in borderless printing differs depending upon the printer and although there are printers that enable the amount of extension to be set to large, medium and small values, there are also printers that only allow the amount of extension to be set to a small value. Information that cannot be acquired with an OS-provided default API function as in the manner of amount of extension in borderless printing will be referred to below as “vender-specific information”.
In order that an application program may acquire vendor-specific information in Windows, there is a method of utilizing a vendor-specific API provided by a module of the printer driver. There is also a method in which the application program acquires vendor-specific information from a printer driver by utilizing an API referred to as an “ExtEscape function” provided by the OS.
A method of utilizing a vendor-specific API will be described first. The vendor-specific API is provided by a module constituting the printer driver. There are instances where the module is referred to as a “printer-driver SDK module”. The application program first specifies the printer-driver SDK module. Next, the application program calls a LoadLibrary function, thereby loading the printer-driver SDK module into the address space of the process of the application program. The application program then calls the function of the vendor-specific API, which is provided by the printer-driver SDK module, whereby it can acquire the vendor-specific information (e.g., see the specification of Japanese Patent Laid-Open No. 2004-288013).
A method using the ExtEscape function will be described next. The ExtEscape function is an API provided by the OS and is used in order to transfer unique data between an application program and a printer driver. For example, the ExtEscape function is used when the application program determines whether the printer driver is equipped with an interface for executing its own image processing (e.g., see the specification of Japanese Patent Laid-Open No. 10-248014).
Since there are printers of many types and capabilities differ from one type to another, a printer driver is required for every type of OS. In the case of Windows, a large number of printer drivers are bundled with the OS product. Even if a printer driver is not bundled with the OS product, the OS is designed so that the appropriate printer driver is downloaded from Microsoft automatically via a network. Thus, with Windows, an environment is provided in which a large variety of printers print. Windows includes both a 32-bit version of the OS and a 64-bit version of the OS. Since a printer driver operates in close relation with the OS, a printer driver bundled with the 32-bit Windows product is a 32-bit printer driver and a printer driver bundled with the 64-bit Windows product is a 64-bit printer driver. The same holds true of printer drivers downloaded automatically. A 64-bit printer driver is downloaded in the case of the 64-bit version of the OS, and a 32-bit printer driver is downloaded in the case of the 32-bit version of the OS.
Further, there are two types of printer drivers that operate with Windows, namely a GDI printer driver and an XPS printer driver. GDI stands for “Graphics Device Interface”. This is a program, supplied by Windows, for allowing the application program to instruct graphic rendering that is independent of the output device. A characterizing feature of the GDI driver is that a rendering module of the printer driver interprets the rendering instruction of the application program implemented via the GDI and executes print processing.
On the other hand, one of the features of an XPS printer driver which can be mentioned is that the format of device-independent print data stored in a spool file is the XPS format. XPS stands for XML Paper Specification and is one open-standard electronic document format provided by Microsoft. The rendering instruction of the application program implemented via GDI is stored in a spool file upon being converted to XPS by an MXDC (Microsoft XPS Document Converter) provided by Microsoft. A rendering filter of the XPS printer driver interprets the XPS so that printing is executed. Here the MXDC of the XPS printer driver corresponds to the rendering module of the GDI printer driver.
FIG. 2 is an example of a schematic view illustrating the relationship between an application program 201 and a printer driver in a method utilizing a vender-specific API. In a case where the application program 201 utilizes a vendor-specific API function 213, the program loads a vendor-specific API providing module 211 into address space 203 of the application program process, as mentioned earlier. Initially, therefore, it is required that the application program 201 specify the module name of the vendor-specific API providing module 211. For example, by calling a GetPrinterDriver function, which is an OS-provided API, the application program 201 can acquire the file names of a user interface module and rendering module from among the modules constituting the printer driver. Owing to the fact that the user interface module or rendering module includes a vendor-specific API function 213, the application program 201 is capable of specifying the module name of the vendor-specific API providing module 211. Further, in a case where a vendor-specific API is provided by a module other than a user interface module or rendering module, it may be so arranged that the module name of the vendor-specific API providing module 211 is specified using an ExtEscape function, described later. After the vendor-specific API providing module 211 is loaded into address space 203 of the application program process, the application program 201 acquires the address of the vendor-specific API function 213 and calls this function.
FIG. 3A is an example of a schematic view illustrating the operation of the ExtEscape function, which is an OS-provided API. By utilizing the ExtEscape function, the application program 201 and printer driver are capable of passing vendor-specific information. A print support feature 301 of the OS is a feature provided by the OS. Through the print support feature 301, the OS executes processing of the API function called by the application program 201 and calls the printer driver as necessary. A user interface module 311 and a rendering module 321 are included in a group of modules constituting the printer driver. The user interface module 311 has a feature for allowing the user to configure various items relating to printing and for creating print settings based upon indications from the user. The rendering module 321 has a feature for converting a rendering instruction of the application program 201, which has been accepted via a GDI, to an image or for converting it to page description language.
The application program 201 designates a vendor-specific Escape code (S311) as the argument of the ExtEscape function in order to obtain the desired vendor-specific information as in the form of a list of amounts of extension in borderless printing, by way of example. At the same time, data necessary for Escape processing, described later, is passed as the argument of the ExtEscape function. When the application program 201 calls the ExtEscape function, the print support feature 301 of the OS calls a DrvDocumentEvent function of the user interface module 311 of the printer driver (S312). The DrvDocumentEvent function is capable of referring to the argument when the ExtEscape function is called by the application program 201. When notification of the Escape event is given and processing of the DrvDocumentEvent function ends (S313), the print support feature 301 allows the OS to call a DrvEscape function (S314) of the rendering module 321 in the printer driver. The DrvEscape function is capable of referring to the argument when the application program 201 calls the ExtEscape function. The DrvEscape function executes processing conforming to the argument and generates return data of the ExtEscape function. Here the return data is arranged to include the vendor-specific information. The return data generated by the DrvEscape function is returned to the application program 201 via the print support feature 301 of the OS (S315 and S316).
In a case where a 32-bit application program in the 32-bit version of Windows or a 64-bit application program in the 64-bit version of Windows has called the ExtEscape function, the printer driver generally operates in a process the same as that of the application program. On the other hand, in a case where the 32-bit application program in the 64-bit version of Windows has called the ExtEscape function, a 64-bit printer driver operates in a 64-bit process that is different from the 32-bit process of the application program.